Множество людей в последнее время ищут альтернативу WordPress. Эта статья сравнивает WordPress и October CMS, раскрывая важные проблемы, которые нужно держать в уме при поиске подходящей системы управления для ваших проектов.
Некоторое время назад WordPress наконец-то выпустил редактор Gutenberg, чтобы расширить возможности редактирования контента, что заставило многих людей, недовольных этим изменением, искать альтернативы. Появились люди, которые отделили и выпустили до-гутенберговский WordPress – ClassicPress. Однако для меня такой поворот не имел смысла, поскольку у WordPress всё ещё остаётся 15 лет технических недоработок. Если бы я искал альтернативу WordPress, я бы избегал зацикливания на прошлом и нацеливался б на зрелую платформу, построенную на современных принципах.
В этой статье WordPress сравнивается с вероятно похожей, но более современной CMS October по большому спектру технических и не технических возможностей. Целью этого сравнения не является убедить людей придерживаться WordPress или переключиться на October CMS, но просто продемонстрировать какие моменты нужно учитывать перед переходом на другую платформу. Такое же сравнение можно (и даже нужно) сделать с другими платформами, чтобы сделать осмысленный выбор.
Почему October CMS?
Я узнал об October CMS когда эта система выиграла приз. После чего я переключился в исследовательский режим и потратил хороший кусок времени углубляясь в эту CMS с точки зрения и пользователя, и разработчика. По мере возрастания моих знания об этой системе управления сайтами, я почувствовал уверенность, что я могу предоставить объективную оценку её преимуществ в сопоставлении с WordPress. Я выбрал эту CMS для сравнения среди таких альтернатив как Grav, Statamic, ButterCMS, Joomla, Drupal, Jekyll, Hugo и других, по следующим причинам:
- Я знаю как эта CMS работает (в отличие от Grav);
- Она бесплатна и с открытым кодом (в отличие от Statamic и ButterCMS);
- За последние пять лет она относительно новая (в отличие от Joomla и Drupal);
- У неё динамический (а не статический) генератор контента и основан на PHP (в отличие от Jekyll и Hugo).
Я верю, что October CMS хороший кандидат, т.к. она основана на Laravel, на фреймворке, который используется для создания современных приложений. После семи лет существования он получил позитивную оценку от разработчиков (как доказательство – его ощутимое сообщество и экосистема), и показывает ощутимый контраст по сравнению с кодингом на WordPress. Т.е. WordPress это в основном процедурное программирование, в то время как Laravel – явно объектно-ориентированное программирование.
В чём разница между этими двумя?
Ниже я буду сравнивать WordPress и October CMS по разным критериям и выделять то, что, как мне кажется, является хорошим или не очень хорошим в них. Однако, я не буду выбирать победителя, т.к. это не предмет этой статьи, и, в любом случае, нет самой лучшей или даже просто лучше CMS: каждая CMS имеет свои сильные и слабые стороны, которые делают её более подходящей для тех или иных задач, проектов, компаний, команд и чего угодно ещё. Кроме того, проект может только выиграть от использования более, чем одной CMS, например, используя какую-то CMS для управления и распространения данных, а другую – для внешнего отображения. Решить какая из десятков CMS наиболее подойдёт для ваших нужд предстоит исключительно вам.
Кроме того, эта статья не предоставит окончательный вывод, т.к. она касается только лишь всех возможностей. Например, мы можем найти сравнения “Wordpress vs Drupal vs Joomla”, “Wordpress vs Генератор статических сайтов” или даже “Wordpress vs Medium”. Но ни одна из этих статей не предоставит полной картины, ни одно из этих сравнений не будет заключительным, и не должно рассматриваться как таковое.
Давай начнём сравнивать.
Философия и целевая группа
То, что на WordPress работает около одного из трёх сайтов, не случайное совпадение. С самого своего начала эта система управления стремилась быть с очень дружественным интерфейсом, и делала это успешно, избавляясь от сопротивления как технических и нетехнических пользователей, так и людей всех слоёв общества, независимо от уровня их образования и достатка. Основатель WordPress Мэтт Мулленвег сказал, что девиз WordPress “Демократизация публикаций” для сегодняшнего времени означает следующее:
Люди любого происхождения, интересов и возможностей должны иметь доступ к бесплатному программному обеспечению, которое даст им возможность выражать себя в интернете и владеть своим контентом.
WordPress прост в использовании для всех, и его инклюзивность подтверждается на стороне разработки: нередко можно встретить людей без навыков программирования (таких как маркетологи, дизайнеры, блоггеры, продавцы и другие), которые работают с настройками WordPress, создают свои собственные темы оформления и успешно запускают свои собственные сайты. WordPress ориентирован на пользователя, и потребности пользователей превосходят потребности разработчиков. Для WordPress, пользователь – король (или королева).
Напротив, October CMS больше ориентирован на разработчиков, что в явной форме признавалось с самого первого релиза:
October делает одно мощное, но очевидное предположение: клиенты не делают сайты, их делают разработчики. Роль клиента это управление сайтом и выражение их деловых потребностей. Разработчик и эта индустрия в целом вертится вокруг этих факторов.
По словам её создателей, миссия CMS – доказать, что создание сайтов не ракетостроение. Будучи основанной на Laravel, October CMS может претендовать на то, что она имеет прочную основу для многократно используемого модульного кода, который может создать правильно спроектированные приложения, поддерживаемые в долгосрочной перспективе и полностью настраиваемые, не требуя каких-то хаков – тип, который привлекает серьёзных программистов. October CMS также очень удобна в использовании, однако, это не та простота и отсутствие лишних телодвижений, что предоставляет WordPress. Пользователям сначала нужно будет объяснить как работает тот или иной функционал прежде, чем они смогут его использовать. Например, встраивание формы из какого-нибудь плагина имеет длинное описание того, как это нужно делать, что достаточно обременительно, в отличие от очевидного и обычного перетаскивания, которое используется несколькими плагинами для создания контактных форм в WordPress.
Установка
WordPress знаменит своей пятиминутной установкой, хотя многие люди отмечают, что (учитывая все плагины, которые должны быть установлены) типичная установка занимает у них 15 минут или более. Вдобавок, WordPress также предлагает функцию “Мультисайт”, которая позволяет создать сеть из множества виртуальных сайтов всего из одной установки. Эта функция облегчает агентствам администрирование сайтов для множества клиентов.
Установка October CMS тоже очень спокойная: Мастер установки сам по себе укладывается даже меньше, чем в пять минут, а если вы устанавливаете её через консоль, то и ещё быстрее. Вы можете использовать консоль просто зайдя в целевую директорию и затем выполнить curl -s https://octobercms.com/api/installer | php (после чего нужно ввести конфигурации базы данных, иначе она поведёт себя как плоская CMS). После того как установка завершена, у нас есть полностью функциональный сайт, но он всё ещё немного голый (если вы добавите время, необходимое на установку и настройку нужных плагинов, вы можете ожидать, что это займёт как минимум 15 минут).
Безопасность
WordPress обвиняют в том, что он небезопасен, ссылаясь на высокое количество уязвимостей, которые постоянно находят. Это заставляет пользователей регулярно обновлять как саму CMS, так и установленные плагины, чтобы избегать взломов. Среди основных проблем – поддержка Вордпрессом старых версий PHP, включая те, которые уже не поддерживаются сообществом разработчиков PHP (WordPress поддерживает на данный момент PHP 5.2.4, в то время как сейчас основной поддерживаемой версией PHP является версия 5.6 (на момент перевода статьи актуальной версией PHP является 7.3)). Тем не менее, проблема должна решиться в апреле 2019, когда WordPress официально будет поддерживать PHP 5.6 и выше.
С другой стороны, WordPress не обязательно небезопасен сам по себе, а скорее из-за его высокой популярности, что делает его основной целью хакеров. Однако это работает в обе стороны: распространённость WordPress означает, что его отдел безопасности должен отнестись к своей работе со всей серьёзностью, постоянно отыскивая уязвимости и исправляя их как можно скорее, иначе треть интернета будет в опасности. Ставки слишком высоки.
October CMS наоборот не считается небезопасным. Однако с начала их существования, всего около 27.000 сайтов работает на October, в то время как на WordPress – миллионы, поэтому мы не можем сравнивать этот момент на одинаковых условиях. Тем не менее, команда, стоящая за October CMS, относится к безопасности серьёзно. В доказательство можно привести установщик, который предлагает указать URL панели администратора. По умолчанию указан “/backend”, но его можно заменить на любой другой, что делает эту систему управления более затруднительной целью для хакеров. В WordPress для изменения URL страниц логина и админки с “/wp-login.php” и “/wp-admin” используются сторонние плагины. Кроме того, October CMS может работать как плоская CMS (т.е. без базы данных) и, соответственно, избегать таких уязвимостей как SQL-инъекции.
Стек технологий
И WordPress и October CMS работают на традиционном LAMP стеке: Linux, Apache, MySQL и PHP. (Однако из этого только PHP не меняется: мы также используем Windows, Ngnix MariaDB и другие.) October CMS может работать на базе статических файлов, что значит, она может работать без базы данных, но ценой отказа от многих функциональных возможностей (например, записи для блога и пользователи). Гарантируется только функциональность страниц, которые считаются основной единицей для создания и публикации контента. Они же поставляются в качестве базовой функции.
Что касается языкового стека, то сайты, созданные как на WordPress, так и на October CMS, основаны на HTML, CSS и JavaScript (обратите внимание, что для генерации HTML используется PHP). В October CMS также легко использовать файлы LESS и SASS.
Парадигма программирования
WordPress придерживается парадигмы функционального программирования, основанной на вычислениях путем вызова функций, не зависящих от состояния приложения. Несмотря на то, что разработчикам WordPress не обязательно придерживаться функционального программирования (например, при создании тем и плагинов), основной код WordPress наследует эту парадигму в результате 15-летнего сохранения обратной совместимости, которая была одной из основ успеха WordPress, но привела к непредвиденным последствиям – накоплению технического долга.
С другой стороны, October CMS придерживается императивной парадигмы программирования, основанной на вычислениях путем манипулирования состоянием объектов. October CMS базируется на Laravel – веб-фреймворке, полностью основанном на принципах объектно-ориентированного программирования, которые позволяют создавать модульные приложения на основе таких концепций, как Model-View-Controller для отделения пользовательского интерфейса от данных приложения, Dependency Injection для настройки зависимостей классов, Interface Segregation Principle для определения основных сервисов, предоставляемых фреймворком, и многих других.
Хуки/События
Программирование в WordPress можно охарактеризовать как HDD, что расшифровывается как “Hook-Driven Development”. Хук – это механизм, позволяющий изменить поведение или значение по умолчанию и дать возможность другому коду выполнить соответствующую функциональность. Хуки запускаются через “actions” (действия), которые позволяют выполнять дополнительную функциональность, и “filters” (фильтры), которые позволяют изменять значения.
Хуки, широко распространенные в кодовой базе WordPress, – это одна из концепций, которая мне больше всего нравится при программировании в WordPress. Они позволяют плагинам взаимодействовать с другими плагинами (или с ядром или темой) чистым способом, обеспечивая некоторую базовую поддержку аспектно-ориентированного программирования.
Хорошей новостью является то, что Laravel (и, как следствие, October CMS) также поддерживает концепцию хуков, которая называется “events” (события). События обеспечивают простую реализацию наблюдателя, позволяя коду подписываться и прослушивать события, происходящие в приложении, и реагировать на них по мере необходимости. События позволяют разделить сложную функциональность на компоненты, которые могут устанавливаться независимо друг от друга, но при этом взаимодействовать между собой, что позволяет создавать модульные приложения.
Зависимость от JavaScript библиотек
В последней версии WordPress для создания контента по умолчанию используется Gutenberg, работающий на основе технологии React. Таким образом, разработка WordPress в настоящее время в значительной степени опирается на JavaScript (преимущественно через React), хотя возможно использование и других фреймворков или библиотек (примером может служить Elementor Blocks for Gutenberg, основанный на Marionette). Кроме того, WordPress по-прежнему использует Backbone.js (для управления медиафайлами) и jQuery (устаревший код), однако можно ожидать, что зависимость от этих библиотек будет ослабевать по мере закрепления Gutenberg в качестве новой нормы.
October CMS зависит от jQuery, который используется для реализации дополнительного фреймворка AJAX, позволяющего загружать данные с сервера без обновления страницы в браузере.
Страницы, шаблоны и плагины
И WordPress, и October CMS рассматривают страницу как основную единицу для создания и публикации контента (в случае WordPress – в дополнение к посту), поддерживают изменение внешнего вида сайта с помощью тем, а также позволяют устанавливать и расширять функциональные возможности сайта с помощью плагинов. Несмотря на то, что концепция обеих CMS одинакова, в их реализации есть некоторые различия, которые приводят к несколько иному поведению.
В WordPress страницы определяются как контент и хранятся в базе данных. В результате содержимое страниц может быть создано только через CMS (например, в панели управления), а переход с одной темы на другую не приводит к тому, что существующая страница становится недоступной. Это создаёт безупречное впечатление.
В свою очередь, в October CMS страницы представляют собой статические файлы, хранящиеся в каталоге темы. Положительным моментом такого архитектурного решения является то, что содержимое страниц может быть создано из внешнего приложения, например, из текстовых редакторов типа Sublime или Visual Studio Code. Отрицательным моментом является то, что при переходе от одной темы к другой необходимо вручную пересоздавать или копировать страницы из текущей темы в новую, иначе они исчезнут.
Важно отметить, что в October CMS маршрутизация осуществляется через страницы, поэтому страницы используются не только как контейнеры для содержимого, но и для функциональности. Например, плагин для ведения блога зависит от страницы для отображения списка записей блога по выбранному URL, другой страницы для отображения одной записи блога по другому выбранному URL и т.д. Если какая-либо из этих страниц исчезнет, то соответствующая функциональность плагина станет недоступной, и на этот URL будет выдаваться сообщение 404. Таким образом, в October CMS темы и плагины не очень хорошо развязаны, и переключать темы нужно очень осторожно.
Функциональность ядра и плагинов
WordPress пытается предоставить минимальную основную функциональность, которая расширяется с помощью плагинов. При принятии решения о включении или невключении той или иной функциональности в основной функционал, WordPress опирается на “правило 80⁄20”. Если она приносит пользу 80% пользователей, то она включается, в противном случае ее место в стране плагинов. Добавление плагинов на сайт может привести к его раздуванию, если установлено слишком много плагинов. Кроме того, плагины могут плохо взаимодействовать друг с другом, выполнять схожий код или загружать схожие ресурсы, что приведет к неоптимальной производительности. Таким образом, если запуск WordPress-сайта относительно прост, то более сложной задачей является его общее обслуживание и сохранение оптимального и производительного состояния при добавлении новых функций.
Аналогично, October CMS также пытается предоставить минимальную базовую функциональность, но на стероидах: единственная гарантированная функциональность – это создание и публикация страниц, а для всего остального необходимо установить тот или иной плагин, что выражается в следующем:
“Все, что нужно, и ничего лишнего”.
Цель понятна: большинство простых сайтов состоят только из страниц, на которых, возможно, нет ни записей в блогах, ни пользователей, ни личных кабинетов пользователей. Зачем же приложению загружать ресурсы для них, если они не нужны? Как следствие, функциональность для ведения блогов, управления пользователями, перевода и т.д. реализована через каталог плагинов.
В ядро October CMS также включены некоторые функции, которые (даже если они не всегда нужны) могут существенно улучшить работу приложения. Например, из коробки поддерживается загрузка медиафайлов на Amazon S3 и доступ к ним через Rackspace CDN. В состав приложения также входит менеджер медиафайлов, который в основном используется через плагины, например, для добавления изображений в запись блога. (Страницы также могут использовать Media Manager для встраивания медиафайлов, однако CMS поставляется с разделом Assets для загрузки медиафайлов, что представляется более удобным).
Я полагаю, что мнительность October вполне может позволить нам создать максимально компактное приложение – в основном для простых сайтов. Однако это может привести и к обратному результату и способствовать раздуванию, поскольку грань между тем, что нужно и что не нужно, является произвольной, и ее трудно заранее установить в CMS. Эту сложность можно оценить, рассмотрев понятие “пользователь”: В WordPress пользователи сайта и администраторы сайта относятся к одной и той же пользовательской сущности (а с помощью ролей и привилегий мы можем сделать так, чтобы пользователь стал администратором). В CMS October они реализованы раздельно, поставляя в ядре реализацию для администратора сайта, который может входить в бэкенд и изменять настройки, а через плагин – для пользователя сайта. Эти два типа пользователей имеют разный процесс входа в систему и разные таблицы базы данных для хранения своих данных, что, безусловно, нарушает принцип DRY (Don’t Repeat Yourself).
Эта проблема возникает не только в отношении поведения сущности, но и в отношении того, какие поля данных она должна содержать. Например, должны ли поля данных пользователя сайта быть предопределены? Обязательно ли поле телефона? А как насчет поля URL Instagram, учитывая, что Instagram стал крутым совсем недавно? Но тогда при создании профессионального сайта не стоит ли вместо этого использовать поле URL LinkedIn? Эти решения, безусловно, зависят от конкретной задачи и не могут быть решены ни CMS, ни плагином.
Плагин для October CMS под названием User реализует пользователей, но без какого-либо пользовательского поля, поверх него плагин User Plus добавляет несколько произвольных пользовательских полей, которых, возможно, недостаточно, поэтому плагин User Plus+ добавляет еще несколько пользовательских полей. Когда, где и как остановить этот процесс?
Другая проблема – когда нет возможности добавить новую функциональность к сущности, что приводит к созданию еще одной, очень похожей сущности, только для поддержки этих необходимых возможностей. Например, October CMS поставляется со страницами и позволяет создавать “статические страницы” с помощью плагина. Природа их одинакова: и страницы, и статические страницы сохраняются в виде статических файлов. Единственное различие между ними (насколько я могу судить) заключается в том, что статические страницы редактируются не в HTML-редакторе, а в визуальном редакторе, и могут быть добавлены в меню. На мой взгляд, только структурные различия, например, когда одна сущность сохраняется в статическом файле, а другая – в базе данных, могут оправдать создание второй сущности для страницы (для этого уже есть запрос), но для простых функций, как это происходит сейчас, это является раздуванием разработки.
Таким образом, хорошо реализованное приложение October CMS может быть очень компактным и эффективным (например, за счет удаления базы данных, когда она не нужна), но, напротив, оно может стать излишне раздутым, вынуждая разработчиков реализовывать несколько решений для одинаковых сущностей, которые могут быть очень запутанными в использовании (“Должен ли я использовать страницу или статическую страницу?”). Поскольку ни WordPress, ни October CMS не нашли идеального решения для устранения раздутости, мы должны тщательно проектировать архитектуру любого из этих приложений, чтобы избежать неприятностей в будущем.
Создание контента
Gutenberg вносит два важных вклада в развитие WordPress: Он использует компоненты в качестве единицы построения сайтов (что дает ряд преимуществ перед программированием блоков HTML), а также вводит сущность под названием “блок”, которая после завершения второй фазы Gutenberg (предположительно в 2019 году) обеспечит единый способ включения контента на сайт, что позволит упростить работу пользователей по сравнению с хаотичным процессом добавления контента с помощью шорткодов, кнопок TinyMCE, меню, виджетов и др.
Поскольку блоки Gutenberg могут создавать и сохранять статический HTML как часть записи в блоге, то установка большого количества блоков Gutenberg не обязательно приведет к раздуванию сайта со стороны пользователя, а может быть ограничена со стороны администратора. Таким образом, Gutenberg можно считать хорошим подходом к созданию сайтов по модульному принципу с простым, но мощным пользовательским интерфейсом для создания контента. Возможно, самым большим недостатком является (неизбежное, но нелегкое) требование изучить React, обучение которому требует значительных усилий и времени.
Если компоненты React являются базовой единицей для создания контента в WordPress, то October CMS основана на предпосылке, что для создания сайтов достаточно знать старый добрый HTML. Действительно, при создании страницы нам просто предлагается редактор HTML (разметки):
Если бы страница представляла собой исключительно статический HTML, то необходимость в CMS отпала бы. Вместо этого страницы October CMS пишутся с использованием шаблонов Twig, которые компилируются в простой оптимизированный PHP-код. Они могут выбрать макет, который включает каркас страницы (например, повторяющиеся элементы, такие как заголовок, подвал и т. д.), могут использовать заполнители, которые определены в макете, чтобы настраивать содержимое страницы, а также могут добавлять частичные блоки, которые являются повторно используемыми фрагментами кода. Кроме того, страницы могут включать блоки содержимого, которые могут быть текстовыми, HTML- или Markdown-файлами, редактируемыми отдельно, и могут прикреплять компоненты, которые представляют собой функциональность, реализованную через плагины. И, наконец, если HTML недостаточно и необходимо создать динамический код, можно добавить функции PHP.
Редактор полностью основан на HTML. Здесь нет текстовой области TinyMCE для добавления содержимого визуальным способом – по крайней мере, не в рамках стандартного интерфейса (эта функциональность принадлежит плагинам). Таким образом, знание HTML можно считать обязательным для использования October CMS. Кроме того, несколько различных способов создания контента (страницы, макеты, заполнители, частичные блоки, блоки содержимого, компоненты и PHP-функции) могут быть очень эффективными, но они определенно не настолько просты, как через единый блочный интерфейс в WordPress. Это может стать еще сложнее, так как можно добавлять и другие элементы (такие как статические страницы, меню и сниппеты), и некоторые из них, например, страницы и статические страницы, кажется предоставляют одну и ту же функциональность, что может вызвать путаницу при принятии решения, когда использовать одно или другое.
В результате, смею заметить, что, хотя практически любой человек может использовать сайт WordPress в качестве администратора, October CMS больше ориентирована на разработчиков, чем на нетехнических пользователей, поэтому программисты могут найти в ней удовольствие, но некоторые другие роли (маркетологи, продавцы и т.п.) могут счесть ее неинтуитивной.
Менеджер медиафайлов
И WordPress, и October CMS поставляются с медиа-менеджером, который позволяет легко добавлять медиафайлы на сайт, поддерживая добавление нескольких файлов одновременно с помощью интерфейса drag-and-drop и отображая изображения в области контента. Они выглядят и ведут себя одинаково; единственное заметное отличие, которое я обнаружил, заключается в том, что медиа-менеджер WordPress позволяет встраивать галереи изображений, а медиа-менеджер October – вручную создавать структуру папок, в которые будут помещаться загружаемые файлы.
Однако с появлением Gutenberg мультимедийные возможности WordPress были значительно расширены: теперь можно вставлять видео, изображения и фотогалереи на месте, а не в текстовой области TinyMCE (которая дает лишь неточную версию того, как это будет выглядеть на сайте), и открывать мощные, но простые в использовании функции.
Локализация
Для перевода тем и плагинов в ядре WordPress используется gettext. Начиная с файла .pot, содержащего все строки для перевода, необходимо создать файл .po, содержащий их перевод на соответствующий язык/локаль, после чего этот файл компилируется в бинарный файл .mo, пригодный для быстрого извлечения перевода. Инструментами для выполнения этих задач являются GlotPress (онлайн) и Poedit (загружаемое приложение). Удобно, что этот механизм работает и для локализации на стороне клиента для Gutenberg.
В настоящее время в ядре WordPress нет решения для перевода контента, и оно не будет реализовано до четвертой фазы Gutenberg (запланирована на 2020+ год). До тех пор эта функциональность обеспечивается плагинами, которые предлагают различные стратегии хранения и управления переведенным контентом. Например, если такие плагины, как Polylang и WPML, хранят каждый перевод в отдельной строке из пользовательской таблицы базы данных (это чище, поскольку не смешивает контент, но медленнее, поскольку требует дополнительного INNER JOIN двух таблиц при запросе к базе данных), то плагин qTranslate X хранит все переводы в одном поле из исходной таблицы базы данных (быстрее для запроса данных, но смешанный контент может привести к разрушениям на сайте, если отключить плагин). Таким образом, мы можем побродить по сайту и выбрать наиболее подходящую для наших нужд стратегию.
October CMS поставляет многоязычную функциональность не через свое ядро, а в виде плагина, созданного командой October CMS, который гарантирует безупречную интеграцию в систему. С функциональной точки зрения этот плагин выполняет свои обещания. С точки зрения разработки, не совсем понятно, как этот плагин работает на самом деле. В WordPress страница – это просто пост с типом записи “page”, и для них существует единый механизм перевода, а в October CMS есть сущности “page”, “static page” и “blog post”, и, несмотря на то, что они довольно похожи, для их перевода требуется три разных реализации! Далее, содержимое “страницы” может включать в себя коды сообщений (например, коды nav.content, header.title и т.д.), каждый из которых содержит свои переводы для всех локалей в виде сериализованного JSON-объекта в таблице базы данных rainlab_translate_messages. Содержимое “статической страницы” создается в новом статическом файле для каждой локали, однако все переведенные URL для всех локалей хранятся не в соответствующем файле, а в файле языка по умолчанию. Содержимое “запись в блоге” хранится в виде сериализованного JSON-объекта с одной строкой для каждой локали в таблице базы данных rainlab_translate_attributes, а переведенный URL хранится с одной строкой для каждой локали в таблице базы данных rainlab_translate_indexes. Я не знаю, связана ли эта сложность с тем, как реализован плагин, или с архитектурой October CMS. В любом случае, это еще один пример нежелательного разрастания на стороне разработчиков.
Управление плагинами
И WordPress, и October CMS предлагают развитый менеджер плагинов, который позволяет искать плагины, устанавливать новые и обновлять уже установленные плагины до последней версии – и все это из внутреннего интерфейса.
Управление зависимостями
October CMS использует Composer в качестве менеджера пакетов, что позволяет плагинам загружать и устанавливать свои зависимости при установке, обеспечивая тем самым безболезненную работу.
WordPress, напротив, официально не принял Composer (или любой другой менеджер зависимостей PHP), поскольку сообщество не может прийти к согласию, является ли WordPress зависимостью от сайта или сайтом. Поэтому, если им требуется Composer для своих проектов, разработчики должны добавлять его самостоятельно. С переходом на Gutenberg npm стал предпочтительным менеджером зависимостей JavaScript, от него зависит популярный набор инструментов для разработчиков, а клиентские библиотеки постоянно выпускаются в виде автономных пакетов в реестре npm.
Взаимодействие с базой данных
WordPress предоставляет функции для получения данных из базы данных (например, get_posts) и их хранения (например, wp_insert_post и wp_update_post). При получении данных мы можем передавать параметры для фильтрации, ограничения и упорядочивания результатов, указывать, должен ли результат передаваться как экземпляр класса или как массив свойств и т.д. Если функция не полностью удовлетворяет нашим требованиям (например, когда необходимо сделать INNER JOIN с пользовательской таблицей), то мы можем запросить базу данных напрямую через глобальную переменную $wpdb. При создании плагина с пользовательским типом поста код, скорее всего, будет выполнять пользовательские SQL-запросы для получения и/или сохранения данных в пользовательских таблицах. Таким образом, на первом этапе WordPress пытается обеспечить доступ к базе данных через общие функции, а на втором – через низкоуровневый доступ к базе данных.
В October CMS используется другой подход: Вместо того чтобы сразу подключаться к базе данных, приложение может использовать Eloquent ORM от Laravel для доступа к данным базы и манипулирования ими через экземпляры классов, называемых моделями (Models), что также делает взаимодействие с базой данных основанным на объектно-ориентированном программировании. Это высокоуровневый доступ; просто следуя правилам создания таблиц и установления связей между сущностями, плагин может получать и/или сохранять данные, не написав ни строчки SQL. Например, приведенный ниже код извлекает объект из базы данных через модель Flight, изменяет свойство и снова сохраняет его:
$flight = Flight::find(1); $flight->name = 'Darwin to Adelaide'; $flight->save();
Модернизация модели данных
Еще одной причиной успеха WordPress (в дополнение к сохранению обратной совместимости) является архитектура базы данных, которая была разработана таким образом, чтобы приложения могли развиваться с течением времени. Эта задача решается с помощью “мета” свойств, т.е. свойств, которые могут быть свободно добавлены к объекту базы данных в любой момент. Эти свойства хранятся не в столбце соответствующей таблицы сущностей (wp_posts, wp_users, wp_comments или wp_terms), а в виде строки в соответствующей “мета” таблице (wp_postmeta, wp_usermeta, wp_commentmeta или wp_termmeta) и извлекаются при помощи INNER JOIN. Таким образом, несмотря на то, что получение этих мета-значений происходит медленнее, они обеспечивают неограниченную гибкость, и для реализации новой функциональности редко приходится перестраивать модель данных приложения с нуля.
October CMS не использует мета-свойства, а может хранить несколько произвольных значений, которые не отображаются непосредственно как колонки в таблицах базы данных, в виде сериализованного JSON-объекта. В противном случае, когда объекту требуется какое-либо новое свойство, необходимо добавить новый столбец в соответствующую таблицу (именно для этого и предназначены плагины User Plus и User Plus+, о которых говорилось ранее). Для обновления схемы базы данных приложения October CMS использует миграции Laravel, которые представляют собой наборы инструкций для выполнения над схемой (например, добавить или удалить столбец, переименовать индекс и т.д.) и выполняются при обновлении программного обеспечения (например, при установке новой версии плагина).
Консольные возможности
И WordPress, и October CMS можно использовать как headless, т.е. рассматривать CMS как систему управления контентом, которая делает контент доступным через API, что позволяет рендерить сайт на стороне клиента и может служить источником питания для других приложений (например, мобильных). Действительно, WordPress уверенно движется в сторону headless, поскольку редактор контента Gutenberg сам по себе рассматривает WordPress как headless CMS (и, как следствие, Gutenberg может работать и с любой другой CMS, что демонстрирует Drupal Gutenberg).
Консольная система должна реализовать некоторый API для возврата данных, например REST или GraphQL. WordPress поддерживает REST через WP REST API (интегрированный в ядро), открывая эндпоинты по некоторому предопределенному маршруту /wp-json/wp/v2/…; October CMS поддерживает REST через плагины RESTful и API Generator, которые позволяют создавать пользовательские эндпоинты и, как следствие, поддерживают версионность как часть URL эндпоинта и могут предложить лучшую защиту от ботов. Что касается GraphQL, то WordPress поддерживает его через WPGraphQL, а October CMS на данный момент не имеет его реализации.
Что немаловажно, безголовая система должна обладать мощными возможностями управления контентом. Как уже говорилось, WordPress имеет очень надежную архитектуру базы данных, предлагающую множество сущностей данных (пользователи, посты и пользовательские посты, страницы, категории, теги и пользовательские таксономии, комментарии), над которыми можно достаточно хорошо смоделировать приложение, мета-свойства для расширения этих сущностей данных (что позволяет приложению обновлять свою модель данных соответствующим образом и без существенных изменений), а с помощью плагина Advanced Custom Fields восполнить пробел для построения отношений между сущностями данных. Кроме того, плагин VersionPress позволяет осуществлять версионный контроль содержимого базы данных с помощью Git. Таким образом, WordPress, несомненно, хорошо подходит для управления контентом, что и было продемонстрировано в ряде проектов.
Со своей стороны, как уже говорилось, October CMS может не иметь базы данных и вести себя как flat-система, либо иметь базу данных и вести себя как гибрид, храня содержимое страниц в виде статических файлов, а посты в блогах (и др.) – в базе данных. Как следствие, контент не является централизованным, и управление им требует иного подхода. Например, если для контроля версий страниц мы можем использовать Git, то для контроля версий базы данных как таковой поддержки нет; решение этой проблемы заключается в загрузке данных в базу через Seeders, которые, будучи кодом, могут быть помещены под контроль версий и выполняться при развертывании. Кроме того, October CMS не предлагает встроенной модели базы данных с предопределенными сущностями данных, которая могла бы удовлетворить потребности большинства приложений. Поэтому, скорее всего, для реализации своей модели данных приложению потребуется собственная разработка, что означает больше работы, но также означает, что она может быть более эффективной (например, доступ к свойству из столбца быстрее, чем из строки другой таблицы через INNER JOIN, как в случае с мета-свойствами WordPress).
Поддержка CLI
Взаимодействие с WordPress и October CMS может осуществляться из консоли через интерфейс командной строки (CLI): WordPress – через WP-CLI, а October CMS – через Laravel’s Artisan. В дополнение к командам Laravel в October CMS реализовано несколько собственных команд для обновления системы, миграции базы данных и др. Эти инструменты позволяют получить доступ к сайту извне браузера, например, для тестирования.
Управляемый хостинг
Найти провайдера управляемого хостинга для WordPress-сайта несложно: учитывая долю WordPress на рынке, существуют десятки (если не сотни) провайдеров, конкурирующих между собой за этот бизнес, что представляет собой очень динамичный рынок. Единственная проблема – найти наиболее подходящего провайдера для конкретного сайта на основе всех его предложений, которые могут различаться по цене, качеству, типу (виртуальный или выделенный), пропускной способности и объему хранилища, поддержке клиентов, местоположению, частоте обновления оборудования и другим параметрам, в которых мы можем ориентироваться в основном благодаря обзорам, сравнивающим их.
Несмотря на то, что их не так много, как WordPress, October CMS все же предлагается несколькими хостинг-провайдерами, что позволяет рассматривать и выбирать. Многие из них указаны как October Partners, а некоторые – как DuckDuckGoing, но поскольку я не нашел ни одного независимого обзора или статьи, сравнивающей их, задача поиска наиболее подходящего потребует некоторых усилий.
Маркетплейс, экосистема и стоимость
Коммерческая экосистема WordPress оценивается в 10 млрд. долл. в год, что свидетельствует о том, сколько людей и компаний смогли заработать на жизнь, предлагая продукты и услуги WordPress, такие как создание сайтов, хостинг, разработка тем и плагинов, поддержка, безопасность и другие. Действительно, его размер настолько велик, что даже раздут, а это значит, что очень часто можно встретить различные плагины, решающие одну и ту же проблему, плагины, которые не дотягивают, не работают или не обновляются годами, и темы, которые кажутся похожими друг на друга. Однако при создании нового сайта размер и разнообразие экосистемы также означает, что мы, скорее всего, найдем хотя бы один плагин, реализующий каждый из требуемых функций, что позволит нам сэкономить деньги, не разрабатывая функциональность самостоятельно, а наличие настраиваемых тем позволит создать достаточно самобытный сайт с минимальными усилиями. Как следствие, мы можем легко создать и запустить сайт на WordPress менее чем за 100$, что делает WordPress разумным вариантом для проектов с любым бюджетом.
Будучи относительно новой (всего пять лет), OctoberCMS, конечно, не может похвастаться размерами рынка и экосистемы WordPress, однако она постоянно растет, поэтому ее размеры будут увеличиваться. В настоящее время на ее рынке представлено 600 с лишним плагинов и всего несколько тем. Что касается плагинов, то команда October CMS просит сообщество направить свои усилия на создание оригинальных плагинов, предоставляющих функциональность, которой пока нет ни в одном другом плагине.
Таким образом, хотя 600+ плагинов – это не так уж и много, по крайней мере, это 600+ различных функциональных возможностей. Таким образом, даже если нет возможности выбирать между несколькими поставщиками, можно рассчитывать на то, что основные функции сайта (такие как ведение блога, комментарии, форум, интеграция с социальными сетями, электронная коммерция и другие) будут покрыты. Кроме того, поскольку основатели October лично проверяют все представленные плагины и оценивают их в соответствии с рекомендациями по качеству, мы можем рассчитывать на то, что эти плагины будут работать так, как ожидается. Еще одним плюсом является то, что в плагины October можно включать элементы из пакетов Laravel (хотя не все они совместимы с October, по крайней мере, без некоторых хаков). Что касается тем, то небольшое количество предложений означает, что, скорее всего, придется разрабатывать собственную тему, нанимая для этого разработчика. Более того, смею предположить, что тема в October CMS, скорее всего, будет собственной разработкой, поскольку темы и плагины не очень хорошо разделены (как уже объяснялось выше), а значит, рынок легко заменяемых тем возникнуть не сможет. (Впрочем, это временная проблема: как только данный запрос будет решен, страницы можно будет хранить в базе данных, и замена тем не должна нарушить функциональность).
На мой взгляд, из-за меньшего предложения тем и плагинов создание простого сайта на OctoberCMS будет стоить дороже, чем создание простого сайта на WordPress. Однако для сложных сайтов более совершенная архитектура OctoberCMS (парадигмы объектно-ориентированного программирования и Model-View-Controller) делает ее более удобной в обслуживании и, как следствие, потенциально более дешевой.
Сообщество
Принадлежность к сообществу WordPress и доступ к нему – одна из самых веских причин для использования WordPress. И дело не только в размере (на WordPress работает почти треть всех веб-сайтов в мире, и сообщество WordPress очень велико), но и в разнообразии. В сообщество WordPress входят люди самых разных профессий (разработчики, маркетологи, дизайнеры, блоггеры, продавцы и т.д.), со всех континентов и стран, говорящие на бесчисленном множестве языков, представители разных социальных, образовательных и экономических слоев, с ограниченными возможностями и без них, из корпоративных, некоммерческих и правительственных организаций и т.д. Поэтому вполне вероятно, что при любой проблеме, с которой мы столкнемся, кто-то сможет помочь на любом из форумов поддержки. Внести свой вклад в развитие WordPress тоже довольно просто: Группа Make WordPress объединяет заинтересованных в поддержке различных проектов (доступность, дизайн, интернационализация и многие другие) и организует способы и регулярность их общения – в основном через специальный канал в рабочем пространстве Slack.
Кроме того, сообщество WordPress реально и осязаемо: оно существует не только в Интернете, но и собирается в офлайне на WordCamps и meetups по всему миру: в 2018 году было проведено 145 WordCamps в 48 странах, на которые было продано более 45 тыс. билетов, и 5,4 тыс. meetup-мероприятий в 687 группах meetup. Поэтому вполне вероятно, что поблизости есть местное отделение, к которому каждый может присоединиться, чтобы попросить помощи, научиться использовать платформу, продолжать учиться на регулярной основе и обучать других. В этом смысле WordPress – это не только CMS, но, что еще важнее, это еще и люди, и решение о переходе на WordPress не должно основываться только на его технических достоинствах, но и на силе его сообщества.
Сообщество October CMS не может сравниться с сообществом WordPress по размеру и разнообразию, хотя оно постоянно растет вслед за ростом популярности этой программы. В October есть форум поддержки, куда можно обратиться за помощью, но он не очень активен. Зато существует довольно активное рабочее пространство Slack, в котором, что немаловажно, регулярно участвуют основатели October, помогая обеспечить надлежащее рассмотрение всех запросов. Этот канал – отличный источник для получения низкоуровневых советов и рекомендаций по работе с программой, однако он ориентирован в основном на разработчиков: Каналов, посвященных вопросам доступности, дизайна, интернационализации и другим темам, как в сообществе WordPress, по крайней мере, пока не существует. В настоящее время не существует конференций, посвященных October CMS, но есть Laracon – конференция сообщества Laravel.
Сопровождение и управление
Можем ли мы быть уверены, что программное обеспечение будет поддерживаться в долгосрочной перспективе, так что если мы решим начать проект сегодня, нам не придется переходить на какую-то другую платформу в будущем? Сколько человек занимается разработкой программного обеспечения? И кто принимает решение о том, в каком направлении будет двигаться программное обеспечение?
На WordPress работает одна треть всех сайтов в мире, поэтому у WordPress нет недостатка в заинтересованных сторонах, вносящих свой вклад в развитие программного обеспечения, и нам не стоит опасаться, что оно придет в упадок. Однако в настоящее время в WordPress идут внутренние обсуждения модели управления, и многие члены сообщества считают, что решения, касающиеся направления развития WordPress, принимаются в одностороннем порядке компанией Automattic, управляющей WordPress.com. Центральное место в этом восприятии заняло решение о запуске Gutenberg, с которым многие члены сообщества были не согласны, и в ходе разработки и выпуска которого руководители проекта не обеспечили должной коммуникации. Как следствие, многие члены сообщества ставят под сомнение роль “доброжелательного диктатора”, которая исторически отводилась основателю WordPress и генеральному директору Automattic Мэтту Мулленвегу, и изучают различные модели управления, чтобы найти более подходящую для будущего WordPress. Пока неясно, приведут ли эти поиски к какому-либо результату, или же статус-кво сохранится.
Решения, касающиеся направления развития October CMS, принимаются в основном основателями компании Алексеем Бобковым и Самуэлем Жоржем, а также разработчиком и комьюнити-менеджером Люком Тауэрсом, благодаря чему проект продолжает развиваться. October CMS пока не может похвастаться проблемами управления: В настоящее время он озабочен тем, как сделать проект устойчивым, приносящим доход разработчикам основного программного обеспечения.
Документация
Документация по WordPress на собственном сайте не является чрезвычайно полной, но она достаточно хорошо справляется со своей задачей. Однако если учесть всю документацию по WordPress из всех источников, таких как общие сайты (Smashing Magazine, CSS tricks и многие другие), специализированные сайты (WPShout, WPBeginner и многие другие), личные блоги, онлайн-курсы и т.д., то практически нет такого аспекта работы с WordPress, который бы еще не был рассмотрен.
October CMS не имеет такого количества сторонних курсов, учебников и записей в блогах, как WordPress, однако документация на ее сайте достаточно полная и, безусловно, достаточная для того, чтобы начать работу. Кроме того, создатели October регулярно добавляют новую документацию в виде учебников. Один из аспектов, который мне лично понравился, – это дублирование документации Laravel в документации October для всего, что имеет отношение к делу, так что читателю не приходится самостоятельно заполнять пробелы и гадать, что относится к October, а что – к Laravel. Однако это не на 100% идеальный вариант. В документации October используются термины, заимствованные из Laravel, такие как middleware, сервисные контейнеры, фасады и контракты, но при этом не объясняется, что это такое. В этом случае полезно заранее ознакомиться с документацией по Laravel (к счастью, документация по Laravel, безусловно, исчерпывающая, а скринкасты Laravel, Laracasts, – еще один прекрасный источник знаний не только по Laravel, но и по веб-разработке в целом).
Заключение
Я задался целью выяснить, какие возможности могут заинтересовать разработчиков, ищущих альтернативу WordPress, сравнив WordPress с аналогичной CMS, которая, по моему определению, должна быть бесплатной и с открытым исходным кодом, базироваться на PHP, создавать динамический контент и пользоваться поддержкой некоторого сообщества. Из всех CMS, удовлетворяющих этим условиям, я выбрал для сравнения CMS October, поскольку получил о ней достаточно знаний, а также потому, что мне понравился чистый и модульный подход к кодированию, реализованный в Laravel, который может предложить свежий и современный взгляд на создание сайтов.
В данной статье не ставилась задача определить победителя, а просто проанализировать, в каких случаях имеет смысл выбирать ту или иную CMS, выделить их достоинства и недостатки. Не существует “лучшей” CMS: есть только наиболее подходящая для конкретной ситуации. Более того, каждый, кто ищет CMS для использования в конкретном проекте с конкретной командой и определенным бюджетом, должен провести исследование и сравнить все существующие предложения, чтобы определить, какая из них наиболее подходит для конкретных условий. Важно не ограничиваться несколькими CMS, как я сделал это в данной статье, а дать шанс всем им.
От себя добавлю, что мне как разработчику очень понравилось то, что я нашел в October CMS, в основном это возможность создания модульных приложений, реализованная в Laravel. Я бы обязательно рассмотрел эту CMS для создания нового сайта. Однако в процессе написания этой статьи я также “заново открыл” для себя WordPress. Будучи столь популярной, WordPress получает более чем справедливую долю критики, в основном касающейся ее старой кодовой базы и, с недавних пор, внедрения Gutenberg; однако WordPress обладает и некоторыми отличными характеристиками (например, супермасштабируемой моделью базы данных), которые редко хвалят, но их тоже следует принимать во внимание. И самое главное, WordPress следует рассматривать не только с технической точки зрения: в частности, размер сообщества и экосистемы ставит его на уровень или два выше альтернатив. Одним словом, некоторым проектам выгодно придерживаться WordPress, а другим лучше опираться на October CMS или другую платформу.
В заключение я хотел бы отметить, что изучение работы другой CMS само по себе является очень полезным занятием, не зависящим от решения о том, использовать эту CMS или нет. В моем случае я много лет работал только на WordPress, и знакомство с October CMS было очень полезным, так как она научила меня многим вещам (например, существованию рекомендаций по стандартам PHP), с которыми я не был знаком через WordPress. Возможно, теперь я решу сменить CMS или останусь на WordPress, зная, как создавать более качественный код.
Источник: https://www.smashingmagazine.com/2019/03/wordpress-october-cms/
